1. Field of the Invention
The present invention relates to the field of telecommunications. More particularly, the present invention relates to determining customer data availability by calculating elapsed time.
2. Background Information
Some advanced intelligent network (AIN) telecommunications services provide a customer with an ability to change customer data, such as a personal identification number (PIN), a telephone number screening list, service options, etc. Typically, in order to make these changes, the customer calls a particular telephone number to connect to an interactive voice response (IVR) that acts as an interface to an element of the telecommunications network, such as a service control point (SCP). The IVR interface is designed to handle multiple and simultaneous calls. The IVR plays pre-recorded announcements and instructs the caller to choose among various options via the touch tone pad. Reacting to the input of the caller, the IVR stores the requested changes in a subscriber's call processing record (CPR) or database table that resides on the SCP. These changes take effect immediately and are available for immediate use by AIN service logic.
For example, a subscriber to an Outgoing Call Control (OCC) service, an AIN service, dials a ten digit OCC update number. A voice tells him to enter the phone number and pin number of the phone that is equipped with the OCC service. After entering the phone number and correct pin, the voice asks the caller to choose among a number of options. As an example, the voice might ask him to enter the number two on the touch tone pad to change the PIN. After entering the two, the customer is instructed to choose a new PIN. Immediately after successfully entering the new PIN and confirmation of the desired change, the new PIN becomes the active PIN.
A problem with this method of customer change involves multiple users updating the same subscriber data. Whenever more than one person has the capability to change a particular subscriber's data, it is always possible that two or more authorized persons might try to initiate changes at the same time. An instance of this might be when two members of a household attempt to add non-restricted exception numbers to the Outgoing Call Control database. Simultaneous changes could have negative results on the subscriber's database. For this reason, a method is needed for “locking out” all but the first of the callers. By locking the subscriber's database during a (dual tone multi-frequency) DTMF update, subsequent callers are prevented from entering conflicting data until the first caller has finished.
A system must also allow for users that abandon the call after their database becomes tagged as “in use”. The tag must be removed after the successful DTMF update and a timer must be used to allow the logic to know that the “in use” tag is no longer valid. Typically, the system sets a duration or time limit to ignore the “in use” switch if the date and time of the last update has passed.
In the current system, a Call Processing Record (CPR) that resides on a service control point (SCP) includes logic that examines the values of an “in use” flag, along with the time and date that flag was last updated and a number of time-out minutes, to determine whether a CPR is in use. If the “in use” flag is set to yes and the timer has not expired, callers will not be allowed to access the data until the current caller has finished updating or the timer expires. If the number of time-out minutes has expired since the flag was last updated, then: the flag is cleared (in use=No); the time and date are reset to the current time and date; and the return value indicates that the service logic should proceed as if the in use flag had not been set.
Currently, logic determines if the time out duration has expired by: comparing the current Gregorian date with the last update Gregorian date and subtracting the current time from the (last update time+the maximum lockout period). Problems arise if DTMF updates are made and the lockout period falls into the next day, i.e., just before midnight. When this happens special logic determines if the call should be locked from DTMF update. Furthermore, daylight savings time is not accounted for by the current method.